1. Úvod

Tento dokument vznikl jako součást programu k bakalářské zkoušce ze základů informačních technologií. Je kompletní dokumentací tohoto programu.

Dokument je rozdělen do několika celků:

1. Zadání - popisuje kontext vytvářeného systému.
2. Autorská dokumentace - hlavní část dokumentace.
3. Uživatelská dokumentace.

Pro popis systému užívám objektových metodik a technologií tak, jak jsou vyučovány na kursech it_357 (Objektově orientované metodiky a technologie = OOMT - analýza) a it_459 (OOMT - design).

Popisovanou firmou je smyšlená cestovní kancelář Cesta s.r.o. Popisovaný informační systém je jakousi evidencí zákazníků, zájezdů a instruktorů.

2. Typografické konvence

Značka	Význam
A_	aktor (Actor)
U_	typ jednání (Use case)
C_	třída aplikační logiky (Class)
TAB_	tabulka v databázi (TABle)
db	databáze

3. Zadání

V této části popíši realitu, ze které systém vychází (slovní popis + kontextový DFD diagram) a požadavky uživatelů na systém (modelj jednání).

3.1. Popis reality

3.1.1. Popis firmy

Cetsovní kancelář Cesta je menší cestovní kancelář v Praze. Tvoří ji 5 zákaznických center, z nichž jedno je současně sídlem firmy.

Svým zákazníkům zprostředkovává zejména dobrodružněji laděné cesty za poznáním na kole, pěšky či po vodě.

3.1.2. Organizační struktura

Firmu vede jediný člověk - šéf. Ten má k dispozici sekretářku, která ho může v různých činnostech zastupovat. V každé pobočce sedí 2 lidé ve funkci obchodní referent; ti přicházejí do styku se zákazníky. Jeden z nich je vždy vedoucím pobočky - to sebou nese větší odpovědnost, nikoli však již plat. Firma dále zaměstnává v místě sídla účetního a administrátorku současného IS (správa databáze a internetových stránek). Občas je třeba kontaktovat externího právního poradce. Dalšími zaměstnanci firmy, kteří ovšem vůbec do styku s IS nepřijdou jsou instruktoři zájezdů, pracujících víceméně na plný úvazek. Sečteno a podtrženo: úzké vedení (2 lidé) - "obslužný personál" (14 lidí + externí právník) - cca 30 stálých instruktorů.

3.1.3. Popis vybraných činností

Ve firmě probíhá sousta činností, zaměřím se jen na ty, které nějak souvisí se zaváděným IS.

Tvorba nabídky zájezdů

Zcela v kompetenci vedení firmy. Rozhodování o zavedení nových zájezdů probíhá po určité diskuzi uvnitř firmy. Pro každý rok se tvoří nová nabídka (do jisté míry kopírující předloňskou) - údaje o minulých zájezdech si přeje mít vedení stále v evidenci. Starší zájezdy tedy zůstavájí v evidenci (včetně toho, kdo je vedl, kdo si kupoval místa), avšak již nejsou dále nabízeny. Problémem je neplánované rušení zájezdů (přírodní katastrofa, politická situace). U takových zájezdů, pokud jsou zrušeny, je nutno zajistit vrácení peněz.

Přiřazování instruktorů na zájezdy

Vedení najímá takové instruktory, kteří budou schopni vést určitý typ zájezdů. O tom, který konkrétní zájezd potom povedou, rozhoduje vedení po diskuzi s instruktory.

Komunikace se zákazníkem

V současné době probíhá jen v pobočkách firmy a pasivně na internetu (nabídka zájezdů). Firma by ráda přenesla komunikaci na Internet (v tom má pomoci i nový systém). Přání zákazníků, na která musí systém reagovat je rezervace místa a zrušení této rezervace. Jak zákazník za místo platí? Není požadována platba v hotovsti na místě. Zákazník může místo rezervovat a do pěti dnů ho zaplatit platbou na účet firmy. Na základě tohoto výpisu pak účetní popř. obchodní referent dané rezervace buď uvolňuje zpět do nabídky nebo je označuje jako zaplacené.

Zákazník také může hodnotit zájezdy a instruktory - činí tak vyplněním anketního lístku. Vše je pochopitelně anonymní.

3.2. Požadavky na systém

Požadovanou funkčnost systému zachycuje model jednání.

Tento model zachycuje, kdo se systémem přijde přímo do styku (aktor = A_) a k čemu systém používá (typ jednání = U_). Názvy jsou samovysvětlující.

A_zákazník U_informace_o_zájezdech A_obchodní_referent U_nový_zakazník U_změna_dat_u_zakazníka U_zrušení_zákazníka U_rezervace_místa U_zrušení_rezervace_místa U_zaplacení_místa A_účetní U_zrušení_rezervace_místa

A_správa_zájezdů U_nový_instruktor U_změna_dat_u_instruktora U_zrušení_instruktora U_nový_zájezd U_změna_dat_u_zájezdu U_zrušení_zájezdu U_změna_dat_u_místa U_přidání_instruktora_k_zájezdu U_změna_aktivity_instruktora U_změna_aktivity_zájezdu

4. Autorská dokumentace

Tento oddíl se dělí na tři pododdíly:

1. Analýza - cílem analýzy je porozumět problému a popsat logiku aplikace.
2. Design - cílem designu je rozhodnout se, jak bude systém implementován - popisuji fyzickou vrstvu aplikace.
3. Implementace - cílem je samotné naprogramování systému.

Rád bych uvedl pár (důležtých) poznámek k analýze, designu a implementaci. Sice tím trochu předběhnu, ale:

Během vytváření systému jsem se dostal do zvláštní situace. Systém je projektován pomocí objektových metodik. V konečné fázi se také počítá s jeho objektovou implementací. Zatím však je však systém implementován v jazyce PHP. Tento jazyk sice umožňuje práci s objekty, ale bylo by dost odvážné nazývat ho objektovým programovacím jazykem. Právě i pro špatnou podporu objektů v PHP jsem se přidržel klasické strukturované implementace. Proč jsem však zvolil nevhodné implementační prostředí? Navíc samotná povaha úlohy - správa databáze (zápisy, změna, prohlížení) - si objektový způsob nijak nezasluhuje, ba co víc, nezdá se ani být příliš vhodný. To vybízí k další (závažnější) otázce: Proč jsem tedy vůbec úlohu řešil objektově?

Během řešení problému se systém rozpadl na tři části.

1. Komunikace aktor - systém.
2. Samotná logika aplikace.
3. Spolupráce s relační databází.

Pokud je logika aplikace vymýšlena objektově, u většiny problémů mi přijde myšlenka objektů (jakožto souhrn popisných dat a jejich chování) přirozenější než modulární procedurální programování. Ať tak či tak, samotná logika aplikace, pokud ji velmi zúžíme, je skutečně jen několik operací nad daty v relační databázi a tedy přístup data × procesy není vůbec špatný (důkazem budiž implementace v PHP). Pokud však přesto budeme analyzovat systém jako součinnost několika objektů, umožní nám to mnoho problémů značně zobecnit (vývoj podsysytémů třeba jako komponent pro další použtí), nehledě na možnosti moderních objektových jazyků (C++, Java) a moderních vývojových prostředí (VCL).

A právě subsystémy komnikace aktor - systém a spolupráce s relační databází byly zamýšleny jako komponenty. Při jejich analýze se objektové řešení přímo nabízelo (odvozené třídy, metatypy). Zájemci viz http://sorry.vse.cz/~xslom03/projekty/, odkazy na předměty it_357 (OOMT - analýza) a it_459 (OOMT - design).

Nyní již mohu odpovědět na výše položené otázky:

• Proč jsem tedy vůbec úlohu řešil objektově? Kvůli komponentám, obecnosti a kráse objektového přístupu.
• Proč jsem však zvolil nevhodné implementační prostředí? Toto implementační prostředí není konečné. Jde o jakési provozorium, které si vyžádali vnější okolnosti - čas a obtíže s programováním pod novým prostředím, kde má být úloha realizována - OS Linux. Na druhou stranu je třeba si uvědomit, že pro samotnou aplikaci, tak jak jsem ji vymyslel je zcela postačující (komponenty jsou v ní jaksi navíc, v PHP nejsou realizovány), spoustu věcí automatizuje (komunikace přes prohlížeč, napojení na databázový server) a nelze ignorovat ani jeho rychlost a opravdu snadnost použití (nejsnáze to lze přirovnat k makrům v jazyce C, se syntaxí právě jazyka C). Pokud bych tedy nechtěl vyvíjet obecné znovupoužitelné komponenty, bylo by ideálním prostředím pro implementaci.

Závěrem budiž řečeno, že zmiňovanými komponentami se nadále nebudu zabývat. Toto rozhodnutí se projeví na obsahu dokumentu tak, že část "Analýza" bude objektová, část "Design" nebude popisovat komponenty a bude odrážet některé změny, které bylo nutné provést kvůli implementačnímu prostředí a část "Implementace" zcela podřídím současné implementaci v PHP. Zájemce o objektovou analýzu, design a implementaci komponent odkazuji na výše zmíněnou stránku.

4.1. Analýza

4.1.1. Pojmový objektový model

Pojmový objektový model

Podstata řešení problému

Úloha není příliš složitá. Cestovní kancelář nabízí zájezdy s určitým počtem míst. Zákazník tato místa (resp. zájezdy) kupuje. Každý zájezd vede alespoň jeden instruktor. Zákazník může pochopitelně koupit více míst najednou.

Pro budoucí plánované rozšíření úlohy - viz část "4.2.1. - Vrstvy aplikace", se budou muset přidat nějaká data a přibudou nějaké asociace, avšak model jako takový by se neměl nijak radikálně měnit.

4.1.2. Objektový model

Model odpovědností

Model odpovědností používám k tomu, abych si udělal představu o funkčnosti tříd.

U modelu odpovědností předpokládám:

1. Níže uvedené třídy jsou odpovědné za svá data, včetně správy těchto dat a za další běžné operace (porovnání, přiřazení).
2. Modeluji věcnou stránku problému (aplikační logiku), neuvažuji odpovědnosti za komunikaci s aktorem. Komunikace s aktorem bude řešena až v designu. Na tomto místě předpokládám existenci tříd, jež se orientují pouze na tuto komunikaci (v objektovém designu - komponenta).

Následuje seznam odpovědností, přiřazený třídám aplikační logiky (C_).

Odpovědnost	C_ třída
Jaká místa si zákazník objednal Na jaké zájezdy jezdil Nová rezervace	C_zákazník
Správa seznamu určitých zákazníků Nový zákazník Zrušení zákazníka Vyhledání zákazníka	C_zákazníci
Tvorba míst Změna parametrů míst zájezdu Jací instruktoři ho vedou Zaktivnění / deaktivování zájezdu	C_zájezd
Správa seznamu určitých zájezdů Nový zájezd Zrušení zájezd Vyhledání zájezdu Přidání instruktora k zájezdu	C_zájezdy
Jaký zákazník si objednal toto místo Zaplacení místa Rezervování místa	C_místo
Jaké zájezdy vede	C_instruktor
Správa seznamu určitých instruktorů Nový instruktor Zrušení instruktora Vyhledání instruktora Zaktivnění / deaktivování instruktora	C_instruktoři

Objektový model

4.1.3. Věcná omezení

Věcná omezení stanoví požadavky na asociace takové, aby nedocházelo k logickým chybám.

• Zákazník by si neměl objednávat zájezdy, jež se svými termíny kryjí.
• Instruktor může vést v jeden čas jen jedne zájezd.
• Rušení zákazníků, kteří mají nějaké rezervace by nemělo projít, popř. pouze s explicitním povolením.
• Stejně tak rušení zájezdů, které se ještě nekonaly a jsou v nich nějaká rezervovaná místa, by mělo být zakázáno, popř. by měl být alespoň někam zapsán seznam zákazníků, kterých se to týká (a jimž musí být vráceny peníze).

4.2. Design

4.2.1. Zásadní rozhodnutí designu

Již jsem uvedl, že na program (v takovém stavu, v jakém je teď) měla velký vliv volba implementačního prostředí - objektová analýza a neobjektová implementace! Jaké důvody mě k tomu vedly jsem již zmínil v úvodu. Jakým způsobem to ovlivnilo design a implementaci se pokusím popsat nyní. Znovu připomínám, že program zamýšlím implementovat jednou objektově v C++, v prostředí X window OS systému Linux. Navíc dobrá tvorba komponenty zajišťující komunikaci aktor - systém může značně zjednodušit komunikaci se systémem - třeba tak, že bude produkovat výstup ve formátu XML - a tak zajistit skutečnou nezávislost na platformě.

Vrstvy aplikace

V konečné verzi by aplikace měla být realizována aplikačním serverem, jež bude odpovědný za centrální správu dat pro více konkurujících si klientských aplikací. Data bude podle potřeby načítat či zapisovat do (relační) db. Aplikační server bude také poskytovat mnohem více funkcí:

• Zákazníci si budou moci sami rezervovat místa.
• Budou moci hodnotit zájezdy a instruktory.
• Bude poskytovat souhrné informace pro vedení firmy (jaké zájezdy jsou nejoblíbenější apod.).

Zatím systém vypadá takto:

vrstvy:	SQL databáze	<---->	PHP skripty	<---->	HTML stránky
umístění:	db server	<---->	www server	<---->	www klient

Kominikace s klientem

Rozhodl jsem se, že s klientem bude komunikace probíhat přes www prohlížeč. Tento způsob komunikace vyžaduje jisté speciální zásahy do programu. Je to dáno nespojovanou spolupráci www klienta a www serveru. Po vznesení požadavku na server je zpuštěn jeden řetěz procesů (thread), ten je obsloužen a výsledek je zaslán zpět klientovi. Pomineme-li to, že to nutí tvůrce aplikací pro každý požadavek udržovat stavové informace stále znovu (ve skriptech toho dosahuji často elementem INPUT type="HIDDEN" a předáváním parametrů metodou GET), je celý systém vlastně soustavou malých prográmů, zajišťujícíh jednu jedinou věc.

Během analýzy jsem příliš neřešil, jak přesně tato komunikace bude probíhat. Je jasném že se musí řešit tyto problémy - každý aktor má (1) různá oprávnění nad daty, (2) zajímají ho odlišné části dat, (3) přeje si nad nimi provádět odlišné funkce. Proto má každý aktor systému své vlastní stránky. Ty zobrazují to, co si přeje vidět a umožňují mu provádět jen ty operace, které smí nad daty provádět.

4.2.2. Volba architektury

Interakční rozhraní (komunikace s aktorem) + transakční mng (aplikační logika).

Aktor bude komunikovat se systémem zatím přes www prohlížeč. Tato komunikace má své výhody, ale i nevýhody. Mezi základní výhody patří snadnost obsluhy programu uživatelem. Mezi základní nevýhody složité uchovávání stavových informací (HIDDEN položky HTML formuláře, cookies, spojení na db server).

Aplikační logika je zcela logicky realizována transakčním manažerem. Bohužel db server MySQL podporuje transakční zpracování až v případě, že se mu to přímo řekne, což může pouze jeho správce - nejsem si jist, jak to na serveru sorry chodí, takže transakce neužívám (pochopitelně zajišťuji možnost provádění několika atomických operací nad db v jednom logickém celku najednou jinak) - výsledkem je jediná nevýhoda - při neočekávaném pádu systému, hrozí nebezpečí vzniku nekonzistence dat. Viz níže.

4.2.3. Podsystémy

Obecně lze říci, že program se sestává z jednotné datové základny, nad kterou operuje více konkurujících si aplikací. V objektovém designu rozlišuji tři podsystémy (aplikční logika, 2 komponenty), při realizaci pomocí PHP o klasických podsystémech není moc co říci. Presentaci obstará www prohlížeč, položení dotazu db serveru a tvorbu odpovědi (HTML stránky) PHP skript.

4.2.4. Práce s daty

Práce s daty je zde klíčovým problémem. K uložení a organizaci dat používám relační databázi MySQL na systému OS Linux. Nevýhodou v datové úloze může být ignorance transakčního zpracování v MySQL, ale tato databáze poskytuje i jiné mechanismy, jak zajistit konzistenci dat. Věcná omezení kontroluji na úrovni aplikační logiky (PHP skript) a na základě této kontroly zajistím bezpečný průběh atomických operací v db (zamknutí příslušných tabulek, zápis do logsouborů). Musím ale dodat, že k využití originálních logsouborů db MySQL bych potřeboval mít práva správce db serveru - ty pochopitelně nemám. Mohl bych si sice vytvářet vlastní logsoubory, ale nepovažuji to za účelné - ve skutečnosti bych totiž při normálním provozu tato práva měl.

MySQL a transakce. Tvůrci MySQL je neimplementovali do prvních verzí MySQL zcela záměrně - kvůli rychlosti prováděných operací. Neexistenci transakcí obcházeli udělováním výhradních práv na čtení a modifikaci tabulky. Nyní již lze transakce užívat, ale musí se to přímo nastavit. Neznám přesnou konfiguraci MySQL serveru na počítači sorry a raději nic neriskuji a užívám to, co bude fungovat určitě - atomické operace s tím, že konzistenci zajistí (při běhu aplikace) správné zámky na tabulky, v případě pádu pak skutečně dobře vedené logsoubory a zálohy, kterými lze uvést db do konzistentního stavu velmi rychle.

Jedná se o homogenní systém (centrálně uložená databáze, přistupuje k ní více klientů).

Různí aktoři operují s různými daty a spouští nad nimi jiné operace. Každý komunikuje tedy s db po svém. Vyjímkou je aktor A_účetní, jež užívá systém k jediné funkci - Mazání nezaplacených rezervací. pro tohoto aktora a jeho jediný typ jednání jsem nechtěl vytvářet zvláštní aplikaci. Proto používá komunikaci se systémem stejnou, jako A_obchodní_referent, s tím, že používá pouze jeho jednu funkci.

4.2.4. Řízení v programu

Vnější řízení - paralelní (díky Unixu a MySQL). Vnitřní řízení - procedurální.

Z povahy Unixu běží jednotlivé aplikace zcela nezávisle na sobě. Díky způsobu, jakým MySQL obhospodařuje jednotlivé žádosti o službu (v terminologii MySQL = threads = řetězce procesů), lze zajistit bezproblémový běh více aplikací zamykáním příslušných tabulek (viz implementace).

4.2.5. Mezní provoz

1. Inicializace - nejsou potřeba žádné neobvyklé operace - pouze musí být k dispozici síťové služby a běžící db server. Inicializace potom obnáší napojení na db server. Ve skutečné aplikaci by se navíc klient přihlásí do systému zadáním jména a hesla - realizováno skriptem při vstupu na úvodní www stránky aplikace. Při spuštění skriptu se podle potřeby provedou obvyklé operace nutné pro připojení na db server.
2. Ukončení práce v systému - je na klientovi (aktorovi), aby zajistil, že všechna jím právě editovaná data budou ještě před opuštěním www prohlížeče odeslána db.
3. Pád - při pádu nejsou velkým problémem právě editovaná data na straně klienta (těch je velmi málo). Nepříjemné může být narušení konzistence dat, pokud probíhá nějaká větší operace (tj. více atomických operací najednou - transakce). Ačkoli nyní již MySQL transakční zpracování podporuje, já ho nevyužívám (důvody jsou uvedeny výše). Pokud tedy dojde k pádu a nějaká ucelená operace se promítne do db jen z poloviny (což by se nemělo stát při použití transakcí), musí si správce vystačit s využitím kvalitních logsouborů a pravidelných záloh (v dokumentaci MySQLse uvádí, že není problém obnovit db ze zálohy a dostat ji pomocí logsouborů do aktuálního stavu - do logsouborů jsou totiž zapisovány veškeré destruktivní operace nad databází, ty pak stačí nad obnovenou db spustit jako db skript). Pokud budou transakce skutečně vyžadovány, lze samozřejmě nastavit, že se mají užívat - k tomu ovšem potřebuji oprávnění, která nemám. Nutno poznamenat, že stabilita jak systému Linux, tak serveru MySQL je značná; riziko pádu je tudíž malé. Navíc výhodou neexistence transakcí je vysoká rychlost probíhání db operací.

4.2.6. Určení priorit zpracování

Cílem je imlplementovat aplikaci, tak jak je zde popsána. Pro každého aktora budu vytvářet vlastní aplikaci (vlastní PHP skripty), zřejmě v tomto pořadí:

1. A_správa_zájezdů
2. A_obchodní_referent
3. A_účetní
4. A_zákazník

4.2.7. Testování

Testy provedu na cvičné db o několika málo záznamech. Pouze ověřím logickou funkčnost systému, nebudu řešit jeho skutečné zatížení.

4.3. Implementace

Tato část bude zcela podřízena současné implementaci v neobjektovém prostředí PHP.

4.3.1. Statický popis systému

ERA diagram

Jsou pochopitelně jen vyznačeny vazby mezi tabulkami, které jsou v db. Pokud chci např. zjist, na jaké zájezdy jezdí zákazník, lze to učinit vhodným SQL dotazem (viz níže, popř. zdrojový kód).

Atributy entit

Atributy entit popíši nejlépe db skriptem pro tvorbu tabulek.

CREATE TABLE ins (
  id		INT NOT NULL,
  jmeno		VARCHAR(20) DEFAULT '<jmeno>',
  prijmeni	VARCHAR(20) DEFAULT '<prijmeni>' NOT NULL,
  aktivni	ENUM ('ano', 'ne') DEFAULT 'ano' NOT NULL,
  pocet_hodnoceni INT DEFAULT '0' NOT NULL,
  hodnoceni	INT DEFAULT '0' NOT NULL,
  rc		CHAR(11) DEFAULT '<rod_cislo>' NOT NULL,
  PRIMARY KEY(id)
);

CREATE TABLE mis (
  id		INT NOT NULL,
  cena		DOUBLE(8, 2) DEFAULT '0.00' NOT NULL,
  rezervace	DATE DEFAULT NULL,
  zaplaceno	DATE DEFAULT NULL,
  zaj_id	INT NOT NULL,
  zak_id	INT DEFAULT NULL,
  PRIMARY KEY(id)
);

CREATE TABLE zaj (
  id		INT NOT NULL,
  nazev		VARCHAR(30) DEFAULT '<nazev>' NOT NULL,
  zacatek	DATE DEFAULT '0000-00-00' NOT NULL,
  konec		DATE DEFAULT '0000-00-00' NOT NULL,
  aktivni	ENUM ('ano', 'ne') DEFAULT 'ano' NOT NULL,
  pocet_hodnoceni INT DEFAULT '0' NOT NULL,
  hodnoceni	INT DEFAULT '0' NOT NULL,
  url		VARCHAR(40) DEFAULT '<http://>' NOT NULL,
  PRIMARY KEY(id)
);

CREATE TABLE zak (
  id		INT NOT NULL,
  jmeno		VARCHAR(20) DEFAULT '<jmeno>' NOT NULL,
  prijmeni	VARCHAR(20) DEFAULT '<prijmeni>' NOT NULL,
  mesto		VARCHAR(30) DEFAULT '<mesto>' NOT NULL,
  ulice		VARCHAR(30) DEFAULT '<ulice>' NOT NULL,
  psc		CHAR(5) DEFAULT '<psc>' NOT NULL,
  rc		CHAR(11) DEFAULT '<rod_cislo>' NOT NULL,
  PRIMARY KEY(id)
);

CREATE TABLE asoc_ins_x_zaj (
  ins_id	INT NOT NULL,
  zaj_id	INT NOT NULL,
  PRIMARY KEY(ins_id, zaj_id)
);

4.3.2. Dynamika systému

V tomto bodě popíši dynamiku systému pouze z pohledu probíhajících činností. K tomuto popisu mi poslouží slovní scénáře typů jednání (U_), odvozených v modelu jednání. Každý typ jednání lze chápat jako činnost (jako souhrn procesů, které jsou nutné k tomu, aby tato činnost byla uspokojivě vyřešena). Popisují akce uživatele a reakci systému.

Používám toto značení:

A:	Akce aktora (zmáčknutí tlačítka, následdování odkazu)
S:	Akce systému (provedení skriptu - pokud je složitější, je to rozfázováno)
?:	Dotaz systému (očekávání akce od aktora, potvrzení akce aj.)

Vesměs lze říci, že veškeré typy jednání vlastně zajišťují prostou manipulaci s daty prostřednictvím prohlížeče. Po té co uživatel zvolí jistou operaci, je vygenerována HTML stránka, jsou do ní popř. načteny data z db. Uživatel provede, co chtěl, a odešle stránku zpět www serveru. Pokud je to potřeba je provedena kontrola dat, je vyžádáno potvrzení akce. Následně jsou změny promítnuty do db anebo jsou zrušeny. Většinou to končí návratem na úvodní stránku.

A_zákazník

U_informace_o_zájezdech

1. A: vyvolá funkci (zadá URL do prohlížeče)
2. S: zobrazí souhrné informace o zájezdech
3. ?: čeká na akci aktora
4. A: výběr detailních informací
5. S: zobrazí informace
6. A: může celý postup opakovat, ukončí přechodem na jinou www stránku

Poznámka: U dalších typů jednání předpokládám, že uživatel má spuštěnu aplikaci - tj. má zobrazenu úvodní stránku, odkud vyvolal příslušnou operaci (tlačítkem, odkazem). Navíc, protože u většiny typů jednání končí činnost vypsáním hlášení o úspěchu / neúspěchu akce a návratu na úvodní stránku, po té, co uživatel zprávu vezme na vědomí, mnohdy to ani neuvádím.

A_obchodní_referent

U_nový_zakazník

1. S: zobrazí formulář
2. A: vypní formulář
3. S: dokud není formulář správně vyplněn, opakují se předchozí kroky
4. S: zapíše do db
5. S: podá zprávu užvateli o zápisu do db (úspěch / neúspěch)
6. A: potvrdí
7. S: návrat na úvodní stránku

U_změna_dat_u_zakazníka

1. S: zobrazí formulář, kde jsou načteny data o vybraném zákazníkovi.
2. A: provede změny a odešle
3. ?: potvrzení
4. A: rozhodne (a/n)
5. S: provede akci, vypíše zprávu, očekává potvrzení (odklepnutí)
6. S: návrat na úvodní stránku

U_zrušení_zákazníka

1. S: překontroluje data, jestli nejsou žádné rezervace, podle toho povolí zrušení
2. A: potvrdí zrušení
3. S: provede akci a vypíše hlášení

U_rezervace_místa

1. S: zobrazí rezervace daného zákazníka
2. A: zvolí novou rezervaci
3. S: nechá vybrat ze zájezdu, ze kterého má být rezervace
4. A: vybere
5. S: vyžádá si potvrzení
6. A: potvrdí nebo zruší
7. S: provede akci a vypíše hlášení

U_zrušení_rezervace_místa

1. S: zobrazí rezervace zákazníka
2. A: vybere, kterou rezervaci si přeje zrušit
3. S: požádá o potvrzení akce
4. A: potvrdí nebo zamítne
5. S: provede akci (provede se update, zajistí se i další návaznosti)

U_zaplacení_místa

1. S: zobrazí rezervace zákazníka, které nejsou zaplaceny
2. A: určí, které je zaplaceno
3. S: vyžádá si potvrzení
4. A: potvrdí
5. S: provede změnu

A_účetní

U_zrušení_rezervace_místa

Viz výše.

A_správa_zájezdů

U_nový_instruktor

Probíhá obdobně, jako U_nový_zákazník (tzn. kontrola dat, zápis do db).

U_změna_dat_u_instruktora

Probíhá obdobně, jako U_změna_dat_u_zákazníka (tzn. načtení dat, kontrola nových dat, zápis do db).

U_zrušení_instruktora

Probíhá obdobně, jako U_zrušení_zákazníka, s tím rozdílem, že jsou zrušeny i veškeré informace o tom, které zájezdy vedl.

U_nový_zájezd

Probíhá obdobně, jako U_nový_zákazník (tzn. kontrola dat, zápis do db).

U_změna_dat_u_zájezdu

Probíhá obdobně, jako U_změna_dat_u_zákazníka (tzn. načtení dat, kontrola nových dat, zápis do db).

U_zrušení_zájezdu

Probíhá obdobně, jako U_zrušení_zákazníka, s tím rozdílem, že:

1. Je-li rušen zájezd, který již není aktuální (není aktivní), jsou zrušeny i veškeré informace o tom, kteří instruktoři ho vedli.
2. Je-li rušen zájezd aktivní, operace probíhá jako ad 1., navíc jsou vypsáni zákazníci, kteří již si rezervovali místa (popř. zaplatili). Ti pak musí být nějak o celé záležitosti informováni.

U_změna_dat_u_místa

Probíhá obdobně, jako U_změna_dat_u_zákazníka (tzn. načtení dat, kontrola nových dat, zápis do db). Avšak je tu jeden rozdíl. Změna dat u jednoho místa v zájezdu se aplikuje na všechna místa v zájezdu, která ještě nejsou rezervovaná.

U_přidání_instruktora_k_zájezdu

1. A: vybere zájezd, ke kterému má být přidán instruktor
2. S: nabídne instruktory, kteří mohou být přiřazeni na daný zájezd
3. A: vybere
4. ?: žádá potvrzení
5. S: na základě potvrzení provede akci a vypíše hlášení

U_změna_aktivity_zájezdu

Probíhá v rámci U_změna_dat_u_instruktora (zájezd je vyřazen z nabídky).

U_změna_aktivity_instruktora

Probíhá v rámci U_změna_dat_u_instruktora (instruktor se od této chvíle považuje za propuštěného).

5. Uživatelská dokumentace

Tato část nemusí být nijak rozsáhlá, protože se systémem uživatel komunikuje prostřednictvím internetového prohlížeče. Veškeré ovládání je tudíž grafické (pomocí standardních grafických prvků) a předpokládám, že uživateli známé; pokud tomu tak není odkazuji zájemce na nápovědu prohlížeče. Předpokládám tudíž, že uživatel ví, co to je odkaz, formulář apod..

Musím zde podoknout, že chování programu (oficiální distribuce) bude trošku odlišné. Důvody, proč tomu tak je, vysvětluji v části "Implementace". Obecně mohu na tomto místě říci, že bych k ideálnímu provozování programu potřeboval oprávnění, která nemám (administrace unixového systému, administrace databáze MySQL).

5.1 Spuštění programu

Program spustíte tak, že do spuštěného prohlížeče zadáte adresu, kterou Vám sdělí správce systému. Prosím, uvědomte si, že podle toho, jakým způsobem se systémem pracujete, podle toho se liší adresa. Pro testování prototypu je ale adresa stejná pro všechny uživatele systému: http://sorry.vse.cz/~xslom03/bak_it/src/uvod.html.

Po zadání adresy Vás uvítá hlavní obrazovka. Doporučuji, abyste si tuto stránku zavedli do svých oblíbených položek - kdykoli se v systému "ztratíte", můžete se bez problémů dostat zpět. Úvodní stránka se nijak neliší od jiných internetových stránek. Klikáním na odkazy, vyplňováním jednoduchých formulářů plníte svoji každodenní práci.

Možná budete muset dodržovat určitá nastavení ve Vašem prohlížeči (sdělí Vám správce), prosím dodržujte tato nařízení. Zajistíte tím bezproblémový běh aplikace.

Není vyloučeno, že systém bude požadovat vaši identifikaci (zadání uživatelského jména a hesla) - opět Vám vše potřebné sdělí správce. Prototyp žádné identifikační procedury nevyžaduje. Hlavní stránky jednotlivých uživatelů jsou veřejně dostupné z výše uvedené stránky.

5.2. Práce s programem

Informační systém by měl plnit určité funkce. Tyto funkce se liší podle toho, jaký uživatel se systémem pracuje. Pakliže se umíte pohybovat v prohlížeči, umíte spouštět i jednotlivé funkce systému. Jaké funkce můžete provádět? Podívejte se prosím na model jednání v části "Zadání". Slovem aktor, je označován určitý druh uživatele (snadno z názvu poznáte, jakým aktorem jste) a souslovím typ jednání jsou označeny Vaše možné akce se systémem. Anebo si spusťte Vaši hlavní stránku.

Ačkoli je práce se systémem velmi snadná, je dobré dodržovat určité zásady:

• Nikdy neměňte ručně adresu v položce location Vašeho prolížeče, pokud opravdu nevíte, co děláte.
• Nepřerušujte nahrávání stránky. Počkejte, až se stránka nahraje celá. Pracujete s citlivými údaji a není dobré jen tak z rozmaru ukončit práci v polovině, ještě než stačí proběhnout celá. Vaše síť byla navržena takovým způsobem, abyste nemuseli na provedení operace čekat dlouho.

5.3. Ukončení programu

Program nemusíte nijak ukončovat - skončí vlastně tak, že dokončí nahrávání právě aktuální stránky. Jinými slovy, ukončíte ho stejně jako ukončujete prohlížení internetových stránek - zavřete prohlížeč.